Summary

• Add per-workflow-template locking to prevent race conditions when multiple groups dispatch the same workflow
• Wait inline for run ID matching after dispatch while holding the lock
• Ensures sequential dispatch for jobs targeting the same owner/repo/workflow_id

Problem

When multiple groups (A, B) trigger the same workflow (owner/repo/workflow.yaml), there was a race condition:

T0:      Group A triggers workflow X
T0+100ms: Group B triggers workflow X (same workflow)
T5s:     trackRuns() polls GitHub, finds Run1 and Run2
         -> Job A's findWorkflowRun() picks Run2 (most recent) ❌ WRONG
         -> Job B's findWorkflowRun() picks Run1 ❌ WRONG

GitHub's workflow_dispatch API returns 204 No Content with no run ID, so the system must poll and match by timestamp. Without locking, concurrent dispatches to the same workflow could get each other's run IDs.

Solution

Add per-workflow locking with inline run ID matching:

1. Lock key: owner/repo/workflow_id
2. Flow:
   • Acquire lock before triggering
   • Trigger workflow dispatch
   • Mark job as triggered
   • Poll for run ID (up to 60s, 5s intervals) while holding lock
   • Release lock after run ID found or timeout

This ensures only one job at a time can dispatch and match a specific workflow template.

Test plan

• Build passes
• Configure two groups with the same workflow template
• Enqueue jobs in both groups simultaneously
• Verify each job gets the correct run ID (check logs for sequential dispatch)
• Verify tracking loop still works as fallback if inline matching times out